REMARKS 



Claims 3 and 4 have been cancelled without prejudice. 
Claim Rejections 35 USC ^103 

Applicant acknowledges the Examiner's indication that claims 13 and 19 
would be allowable if rewritten in independent form. However, Applicant respectfully 
maintains that "ChaiTime" in combination with Schuster does not disclose the 
features of the present independent claims. 

Claim 1 specifically recites that the steps of "storing computer software code 
in a SIP message" and "executing the computer software code using the second 
node". Software is generally accepted to mean a piece of code which controls the 
functioning of hardware. Therefore Applicant submits that Claim 1 would be 
understood to claim a SIP message including programming which can control 
hardware function at the endpoint and the execution of this programming to cause 
hardware to function in a desired manner. 

As discussed in detail with reference to this application SIP is an application- 
!ayer signaling protocol. It is described in IETF RFC 2543 which defines the protocol 
as being a "protocol for creating, modifying and terminating sessions with one or 
more participants" (see abstract). Additionally, the definition of a SIP client given 
within the RFC is "similar to those used by the Hypertext Transport Protocol (HTTP) 
RFC 2068". in RFC 2068 a client is defined as "a program that establishes 
connections for the purpose of sending Requests". 

The Examiner states that ChaiTime discloses the step of storing computer 
software code In a SIP message. Applicant respectfully disagrees, ChaiTime 
discloses that when a particular service is required during a call "a specific MIME 
type, say "media/whiteboard", is used for the request" (P25 column 2). If a terminal 
component associated with the requested type is present on the receiving side then 
the call can be accepted "otherwise an attempt will be made to obtain a resource that 
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can be associated with that MIME type, using dynamic service download" {P25 
column 2), 

Thus, it can be seen that ChaiTime discloses inserting a MIME type into a SIP 
message. As a MIME type is not programming that can control hardware function at 
the receiving endpoint, but merely a descriptor of a type of programming that is 
required, Applicant submits that ChaiTime does not disclose "storing computer 
software code in a SIP message" as recited in Claim 1. 

The Examiner further states that ChaiTime discloses "sending the SIP 
message and computer software code from the first SIP client associated with the 
first node to the second SIP client associated with the second node". Although 
ChaiTime does disclose transmitting the SIP message from the first SIP client to the 
second SIP client Applicant notes that the computer software code that is described 
in the SIP message is obtained using Dynamic Service Download where the first 
node "suggests a location on the internet where the software can be obtained" the 
second node then "downloads the software negotiating one-time use payment with 
the software provider if the software is not public-domain" (Page 22 Column 2). 

Applicant therefore submits that one skilled in the art on reading ChaiTime 
would learn to download computer software from a software provider using known 
techniques and not to transmit it from the first node to the second node. 

Finally, the Examiner asserts that Schuster teaches a method for storing code 
in a SIP message. Applicant respectfully disagrees. 

Schuster states that "program instructions corresponding to the SIP client are 
stored in program memory and executed on a microprocessor or DSP on the HSLIC 
card {Column 8 lines 26 to 29)". The SIP signaling then described in Schuster is 
conventional SIP signaling, for example using an INVITE message, ACK message 
and BYE message. A separate protocol (RTP) is used for data transmission. 
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Applicant submits tinat Scliuster merely describes including a program that 
establishes connections for the purpose of sending Requests on an HSLIC and 
using this program to send traditional SIP messages. Nowhere does Schuster 
disclose or suggest including any programming code within a SIP message. 

As discussed previously with relation to this application SIP messages are 
designed to carry information regarding a communication session that is to be set 
up, for example whether it contains voice only or video, which codecs to use and so 
on. Both the SIP messages described in ChaiTime and Schuster implement these 
type of messages with the messages in ChaiTime being extended to describe the 
type of programs required to take part in a communication session. 

The present invention by storing computer software code in a SIP message, 
which may be used to invite a user's endpoint to the conference, enables the user to 
execute the code at his or her endpoint to automatically join a conference without 
having to locate a software provider to download the code from. 

In view of this, Applicant submits that Claim 1 is not rendered obvious by 
ChaiTime in combination with Schuster. 

Applicant further submits that Claims 20 and 26 to 30 are not rendered 
obvious in view of ChaiTime in combination with Schuster for at least the reasons 
given above. 

Claims 2 to 19, 21 to 25 and 34 are submitted to not be rendered obvious at 
least by virtue of their dependencies. 
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In view of the above, further and favorable reconsideration is urged. 



August 27, 2007 



Respectfully subnnitted, 



rilliam M, Lee, Jr. 
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